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ABSTRACT 



In a point-to-multipoint network having a headend in com- 
munication with a plurality a network terminals over a 
shared network, a network terminal is equipped with a cell 
permit sequencer, which operates in conjunction with a 
AAL1 segmentation and reassembly processor, whereby the 
packing of ATM cells carrying continuous bit rate telephony 
traffic is initially delayed such that the first cell of a new 
communication sequence will be "just ready" for upstream 
transmission to the headend with the arrival of an ensuing 
scheduled transmission permit from the headend, including 
accounting for internal processing and transmission over- 
head. In this manner, the ensuing ATM cells for the respec- 
tive communication sequence will thereby be synchronized 
with the ensuing permits, and delay time at the NT thus 
minimized. 

6 Claims, 17 Drawing Sheets 
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AUTOMATIC SYNCHRONIZATION OF 
CONTINUOUS BIT RATE ATM CELLS IN A 
POINT-TO-MULTIPOINT BROADBAND 
ACCESS NETWORK 

HELD OF THE INVENTION 

The present invention pertains to the field of communi- 
cation networks, including apparatus and data transmission 
protocols for the transport of digital data over a shared 
point-to-multipoint broadband access network. 

BACKGROUND OF THE INVENTION 

Much activity is presently being directed into the design 
and deployment of "point-to-multipoint" broadband access 
networks, wherein downstream signals are broadcast from a 
single head-end facility to multiple end user stations (i.e., via 
"point-to -multipoint" transmission), and upstream signals 
are transmitted from each respective end users to the head 
end facility (i.e., via "point-to-point" transmission), respec- 
tively. It presently anticipated that point-to-multipoint 
broadband access networks will be employed to support a 
variety of independent communication services, such as, 
e.g., traditional two-way telecommunications, broadcast 
video (i.e., CATV) services and a full range of digital 
baseband services. 

Given the wide variety of potential communication ser- 
vices to be supported over point-to-multipoint network 
broadband access networks, it is desirable to provide effi- 
cient digital data transmission protocols for supporting both 
the downstream and upstream communication paths. 
Notably, such networks are well suited to support asynchro- 
nous transfer mode ("ATM") based data transmission, 
whereby data packets or "cells" are periodically assembled 
and transmitted from a sending node, and received and 
disassembled at a receiving node. ATM transmission enables 
the transmission of multiple services over a single commu- 
nication path, whereby individual service bandwidth utili- 
zation may be optimized as a function of the statistical 
activity of each individual service — i.e., wherein the ser- 
vices are "bursty" in nature, so that bandwidth is efficiently 
shared. 

For example, bursty data traffic may include local area 
network ("LAN") traffic, which is traditionally limited to 
private, or closed-loop networks, but may be more fre- 
quently carried over shared public access (e.g., 
telecommunication) networks for greater efficiency in con- 
necting multiple LAN locations. Further, with the explosion 
of recent interest in services associated with the "Internet", 
demand for low cost, high speed two-way digital data 
transport is at an all time high. 

By way of specific example, network architectures and 
data communication protocols for supporting both down- 
stream and upstream transport of ATM-based digital data 
over a point-to-multipoint network comprising a headend 
facility connected to multiple downstream network termi- 
nals ("NTs") via a shared coaxial distribution network are 
disclosed and described in U.S. patent application Ser. No. 
08/772,088, filed Dec. 19, 1996, entitled "Network Archi- 
tecture for Broadband Data Communication Over a Shared 
Medium" (hereinafter referred to as "the '088 application"), 
which is assigned to the assignee of the present invention 
and which is fully incorporated herein by reference. 

As set forth in the '088 application, the headend facility 
is provided with a central HeadEnd Media Access Control 
unit ("HEMAC"), which communicates with respective 
Media Access Control ("MAC") units located in each NT. 
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Digital data is presented to the HEMAC and respective NT 
MAC units via dedicated service interfaces, such as, e.g., 
CBR telephony, ATM, or LAN data interfaces at each 
location. 

s Between the HEMAC and the respective NT MAC units, 
"downstream" data (i.e., from the headend to the NTs) is 
transmitted in continuous serial data frames over a common 
RF carrier frequency, wherein all downstream data frames 
are received by all NTs associated with the respective 

10 downstream RF carrier channel. The NTs evaluate each 
downstream data frame, e.g., based on destination or broad- 
cast address fields, to determine whether it is an intended 
recipient of data contained therein. "Upstream" data (i.e., 
from an NT to the headend) is packetized in ATM cells and 

35 transported in respective data frames from individual NTs in 
TDMA slots over a shared upstream RF carrier channel that 
is separate from the downstream carrier channel. 

As disclosed and described in the '088 application, 
selected downstream transmission rates are in multiples of 8 

20 Khz (i.e. 125 usee) to accommodate basic rate (i.e., CBR) 
telephony traffic. For example, as disclosed in the '088 
application, downstream data frames are formed by two or 
more repeating pairs of frame slots, wherein each down- 
stream frame is transmitted over a 250 usee interval, regard - 

25 less of the number of slot pairs it contains. Notably, all 
downstream frame rates are supported by a single upstream 
data rate. Upstream frame transmission timing is identical to 
the downstream frame transmission timing — , i.e., each 
upstream frame is also transmitted over a 250 usee interval, 

30 regardless of its payload size. An individually calculated 
upstream transmission delay is imposed at each NT so that 
the upstream frames are received serially at the headend 
facility at the same interval timing as the downstream frames 
are being transmitted. 

35 In operation, the HEMAC allocates upstream bandwidth 
to respective NTs based on a selected set of operating criteria 
and service type priorities. In addition to a data "payload", 
each downstream data frame includes an upstream band- 
width "permit" that, depending on the type of permit issued 

40 in a given downstream frame, allows for one or more 
respective NTs to transmit an upstream bandwidth "request" 
in a corresponding upstream data frame. Generally, permits 
are issued by the HEMAC on both a "polling" basis, i.e., 
wherein a permit is targeted to a specific NT, as well as a 

4 5 "contention" basis, i.e., wherein one or more NTs may vie 
for an available upstream request slot. Permits are also 
issued based on specific types of upstream data to be 
transmitted, whereby priority may be given to certain ser- 
vices requiring low cell delay variation ("CDV"), such as 

50 CBR telephony traffic. Permit types also include "sign-on" 
permits for allowing newly activated NTs to make their 
presence known to the HEMAC, and "ranging" permits for 
allowing the HEMAC to W determine, and adjust for, 
respectively, the requisite transmission delay for a respective 

55 NT. 

Because upstream frame transmission is provided in 
TDMA frames corresponding on a one-to-one basis with 
downstream TDMA frames, only one permit is provided in 
each respective downstream frame per upstream carrier 

60 channel. Upstream network capacity may be expanded by 
providing one or more additional upstream RF carrier chan- 
nels. In this manner, respective groups of NTs simulta- 
neously transmit upstream on separate carrier channels in 
response to separate permits issued by the HEMAC in the 

65 same downstream frame. 

In accordance with industry ATM telephony standards, an 
ATM cell carries forty-seven bytes of CBR telephony data 
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sampled at a rate of one byte every 125 usee (i.e., sampled SAR processor, which immediately begins assembly of a 

at the basic telephony rate of 8 KHz). Thus the CBR ATM first CBR ATM cell. In this manner, the first cell will be 

cells are assembled every 125 usee * 47=5.875 msec. To packed and in position for upstream transmission, just as the 

meet this standard ATM transmission timing interval, while third permit in the scheduled sequence arrives at the NT. The 

maintaining a 250 usee frame interval, the '088 application 5 ATM cells will thereby be synchronized with the MAC layer 

teaches the use of a CBR permit scheduler table employed permits, and delay time at the NT thus minimized, 

by the headend controller, which allocates CBR permits Other and further objects, features, aspects and advan- 

alternately at 6.00 msec and 5.75 msec intervals, for an tages of the present invention will become better understood 

overall average of 5.875 msec. tne following detailed description of the accompanying 

However, this CBR permit scheduler fails to account for 10 °' rawm S s * 
further transmission delays inherent hi the overall network BRIEF DESCRIPTION OF THE DRAWINGS 
architecture, including in particular the transmission over- NOTE: FIGS. 1 to 18, along with the accompanying text, 
head time in the NT hardware components between when a are taken from '088 application, and are set forth herein to 
CBR cell is fully constructed at the NT and when it is provide a more full and complete understanding of the 
actually transmitted upstream over the network. For 35 present invention, which is disclosed and described in con- 
example, the inventors of the present application have junction with a preferred embodiment illustrated in FIG. 19. 
discovered that in a presently preferred embodiment of an More particularly: 

NT designed for use on a point-to-multipoint system FIG. 1 is a block diagram of an exemplary broadband 

architecture, such as that disclosed in the '088 application, communication network employing a coaxial distribution 

this additional internal circuit component overhead time can 20 network for transmitting data between a headend facility and 

typically amount to between 0,18 msec and 0.20 msec. multiple network terminals; 

As a result of this overhead, an ATM cell assembled after FIG. 2 is a block diagram depicting the respective down- 
5.875 sec will not be ready for transmission at the arrival of stream and upstream transmission of digital data frames in 
the permit at either 5,75 or 6.0 msec, and will have to wait the communication network of FIG. 1; 
for the next permit cycle, causing an undesirable amount of 25 FIG. 3 is a block diagram of preferred downstream data 
delay in the network. In particular, this time delay will frame formats employing alternate DVB framing slot con- 
manifest itself in the form of an system "echo." figurations; 

SUMMARY OF THE INVENTION FIG ' 4 * a block dia S ram of a preferred DVB framing slot 

30 pair for use in the preferred downstream data frame formats 

The present invention provides systems and apparatus for 0 f FIG. 3; 

use in a point-to-multipoint broadband access network FIG. 5 is a block diagram of a preferred MAC control byte 

architecture, such as that disclosed and described in the '088 allocation in a four DVB framing slot downstream data 

application. In particular, the systems and apparatus of the frame; 

present invention account and compensate for internal cir- 3S FI q 6 fc a Modc of a pre ferred MAC control byte 

cuit component transmission overhead in a network terminal ^cation in a six DVB framing slot downstream data 

("NT'), such that the time between when an CBR ATM cell frame- 

is fully constructed and when it is transmitted to the headend FIG. 7 is a block diagram of a preferred MAC control byte 

is minimize . allocation in an eight DVB framing slot downstream data 

To this end, and in accordance with a general aspect of the 40 frame* 

present invention, a network terminal is equipped with a cell ^ g fa a Wock di of f6fred MAC b tc 

permit sequencer, which operates in conjunction with a to a six byte ^ expansion channel; 

AAL1 segmentation and reassembly ("SAR ) processor, rj „ n • ui 1 j- / c j * a * 

, . it f , . c c 4 A JL* „ . . ™„ FIG. 9 is a block diagram or a preferred upstream data 

wherein the packing of a first CDR ATM cell in a given CBR - ^ ... , . ^ * » • 

. . r & ■ n j i j l J; * *l. ii frame transmitted in response to a contention sign-on per- 

transmission sequence is initially delayed such that the cell 45 mit . 

will be "just ready" for upstream transmission to the head- ^ n „ „ , 

end with the arrival of an ensuing scheduled permit, includ- t 10 15 a b l ock dia S ram of 4 P referred u P s ! ream data 

ing accounting for internal processing and transmission frame Emitted m response to a ranging permit; 

overhead FIG, 11 is a timing diagram illustrating a preferred 

More particularly, in a preferred embodiment, a respective 50 DetW ° rk transmission dela ? P rolocc * 

NT sends an upstream request upon detection of an off-hook FIG * 12 15 a block dia S ram of a P rc f<^ cd upstream data 

condition on an associated subscriber telephony line to frame transmitted m response to an reservaUon mode permit; 

initiate the issuance of regularly scheduled CDR permits KG. 13 is a block diagram of a preferred upstream data 

allowing for upstream transmission of the anticipated CDR fr ame transmitted in response to a contention mode permit; 

telephony traffic. A permit timing slot is assigned by a CBR 55 FIG. 14 is a block diagram of a preferred upstream data 

permit scheduler at the headend and confirmed with the frame transmitted in response to a block request polling 

respective NT in an ensuing downstream data frame. Upon permit; 

detecting the off-hook condition, the NT also notifies its FIG. 15 is a block diagram of a preferred upstream data 

respective cell permit sequencer to anticipate receipt of a frame transmitted in response to a group contention permit; 

first CBR permit from the headend. go FIG. 16 is a functional block diagram of the respective 

Upon receipt of the first permit, the cell permit sequencer headend and network terminal MAC controllers, illustrating 

triggers an internal timer, which is set for an interval equal the process for controlling the transmission and receipt of 

to the anticipated arrival time of a "permit-after-next" (i.e., the respective downstream permits and upstream request 

11 .75 msec), minus both the time required to collect the data slots; 

bytes for the first cell (i.e., 5.875 msec) and a predetermined 65 FIG. 17 is a functional block diagram of the permit 

internal NT transmission and processing overhead time (i.e., selector and spacing processor of the headend controller of 

0.18-0.20 msec). The expiration of the timer arms the AAL1 FIG. 16; 
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FIG. 18 is a CBR permit scheduler table employed by the 28 on either a reserved or "polling" basis, or on a "conten- 

headend controller of FIG. 16; and tion" basis. As described in greater detail below in conjunc- 

FIG. 19 is a functional block diagram of the process at a ^aa with FIGS. 16-18, a "scheduled" basis is also employed 

preferred NT for requesting and synchronizing CBR per- bv * c HEMAC 28 for upstream bandwidth permit alloca- 

jjrik 5 tion for certain low CDV services, such as CBR telephony 

traffic. 

DETAILED DESCRIPTION OF THE DRAWINGS As will be apparent to those skilled in the art, an advan- 
tage of "reservation mode" permits is that they are "colli- 

Referring to FIG. 1, a broadband communication network sionless" and may thus be used by the HEMAC 28 to reserve 

20 includes a headend facility 22, which transmits and jo a porl i OQ 0 f me available upstream bandwidth for a given 

receives digital data over a coaxial distribution network 24 carr ier channel exclusively for one or more specifically 

to and from, respectively, multiple network terminal nodes targeted NTs 26 on a predetermined basis. Reservation mode 

(NTs) 26. The headend facility 22 includes a HeadEnd permits are thus advantageous in heavy network traffic 

Media Access Controller (HEMAC) 28, which controls the conditions in that they insure that all NTs 26 have at least 

transport of various digital data streams between the head- ^ somc opportunity to transmit upstream data. On the other 

end facility 22 and the respective NTs 26. For purposes of hand, "contention mode" permits allow one or more NTs 26 

illustration, the headend 22 is shown equipped with a needing to request upstream bandwidth to "contend" for an 

synchronous telephony (POTS) interface 30, an ATM packet available upstream transmission slot. Thus, contention mode 

interface 32 and a LAN data interface 34, each of which permits are especially advantageous in networks containing 

individually transmit and receive digital data to and from, ^ a relatively large number of NTs 26, wherein a "polling 

respectively, the headend 22. om y> protocol would take too long in finding particular NTs 

The headend 22 is also equipped with a modem 36 for RF 26 needing to request upstream bandwidth, and would waste 

carrier modulating downstream data signals over the coaxial bandwidth in the process by necessarily polling uninterested 

distribution network 24 on a selected RF carrier channel to NTs 26. However, because contention mode permits result in 

all NTs 26 associated with that channel. The modem 36 also ^ collisions between responding NTs 26, they are far more 

demodulates RF carrier modulated upstream data received effective in light network traffic conditions than in heavy 

from respective NTs 26 on one or more upstream RF carrier network traffic conditions. 

channels that are separate from the respective downstream In accordance with a further general aspect of the '088 
data channel. In preferred embodiments, the coaxial distri- application, both contention mode and reservation mode 
bution network 24 is limited to network "trees" having no 30 permits allow a NT 26 to "request" additional upstream 
more than three amplifiers (not shown) along any one route, bandwidth, i.e., a for transmission of upstream data com- 
ix., from the headend facility 22 to a given NT 26, in order prising one or more service go types of varying priorities. A 
to limit the impact of transient noise and distortion on the variation of a reservation mode permit includes a "scheduled 
respective downstream and upstream communication sig- mode" permit that is used to assign a specific, fixed amount 
nals. 35 of upstream bandwidth to a given NT 26, e.g., for a handling 
Each NT 26 is equipped with its own Media Access low CDV telephony traffic carried in substantially evenly 
Controller (NT MAC) 38 for handling various digital data spaced upstream ATM cells. 

streams transmitted between the respective NT 26 and the Each NT 26 associated with the respective downstream 

headend facility 22. Each NT 26 preferably supports one or carrier channel receives and evaluates each downstream 

more of the digital data services handled by the headend 40 frame 48 to determine whether it is an intended recipient of 

facility 22. For example, in the illustrated preferred either an enclosed permit 50, or of some or all of the paylo ad 

embodiment, each NT 26 is equipped with a CBR telephony data 52 contained therein. An NT 26 may thereafter respond 

(POTS) interface 40, an ATM interface 42 and a LAN data to a permit 50 contained in a downstream frame 48 by 

interface 44, respectively, each which individually transmit attaching a header containing a "request" slot 60 to an 

and receive digital data to and from the respective NT 36. As 45 upstream AIM payload cell 62 to , to thereby form an 

will be apparent to those skilled in the art, there is no upstream data frame 58, which is then transmitted upstream 

requirement that any given NT 26 be equipped to handle all by the NT 26 to the HEMAC 28. Although upstream frames 

of the particular data services supported by the headend 22. 58 may differ significantly in bit-size and, thus, data rate 

Each NT 26 is equipped with its own modem 46, which from the downstream frames 48, they are still transmitted 

demodulates downstream data signals received from the 50 and received, respectively, at the same interval timing. As 

headend 22 for processing by the NT's MAC 38. The NT explained in greater detail herein, the varying upstream 

modem 46 also modulates respective upstream data signals transmission distances between the NTs 26 is compensated 

for transmission to the headend 22 over the coaxial distri- for by imposing a calculated transmission delay at each 

bution network 24 on a different respective RF carrier respective NT 26, i.e., depending on its respective distance 

channel. 55 from the headend 22. In this manner, upstream data frames 

Referring to FIG. 2, downstream data is transmitted from 58 arrive serially at the headend 22 — i.e., without interfering 

the headend 22 in continuous (serial) downstream data with each other — in successive intervals corresponding to 

frames 48, which generally include an upstream bandwidth the respective downstream transmission interval of the hea- 

"permit" 50 and payload data 52. In order to dynamically dend 22. 

assign upstream transmission bandwidth, the HEMAC 28 60 Referring to FIG. 3, the downstream data frames 48 are 

issues the upstream bandwidth permits 50 on a "one permit configured to be compatible with existing DVB modem 

per downstream frame" basis for each utilized upstream transmission framing and forward error correction ("FEC") 

carrier channel. As described in greater detail below in standards at the physical layer. In accordance with a still 

conjunction with FIGS. 5-8, the permits 50 are carried in a further general aspect of the '088 application, preferred 

MAC overhead section of each downstream data frame 48. 65 downstream data frames 48 are formed by even pairs of 

In accordan with a general aspect of the '088 application, DVB compatible frame slots ("DVB slots"), designated as 

upstream bandwidth permits are allocated by the HEMAC "A" and "B", respectively, wherein each successive down- 
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stream data frame 48 is transmitted from the headend 22 
during a 250 usee interval, regardless of the number of DVB 
slot pairs it contains. Exemplary preferred downstream 
frame configurations include a first frame 70 comprising a 
double DVB slot pair (i.e., with four total DVB slots), a 
second frame 72 comprising a triple DVB slot pair (i.e., with 
six total DVB slots), and a third frame 74 comprising a 
quadruple DVB slot pair (i.e., with eight total DVB slots), 
respectively, wherein each of the respective DVB slot pairs 
"A-B" in each of the frame configurations 70, 72 and 74 are 
identical. 

Referring to FIG. 4, in conformance with DVB modem 
frame transmission standards, DVB slots A and B each 
comprise two hundred and four data bytes, wherein the 
respective A-B slot pairs are transmitted serially by the 
headend 22, i.e., from left to right. In particular, DVB slot 
"A" (64) of each A-B pair is formed by an initial synchro- 
nization ("sync") byte, which is followed by a first control 
byte-("CTL0"), three successive fifty-three byte ATM cells 
(#s 1-3), the first twenty-seven bytes of a fourth ATM cell 
(#4), and sixteen bytes of FEC information, respectively. 
DVB slot "B" (66) also begins with a synch byte, which is 
followed by a second control byte (CTL1), the remaining 
twenty -six bytes of ATM cell (#4), three additional fifty- 
three byte ATM cells (#s 5-7), a third control byte (CTL2), 
and sixteen bytes FEC information, respectively. 

Thus, as can be calculated from the respective DVB slot 
pair configurations, and based on the preferred downstream 
frame transmission timing of 250 usee, the four DVB slot 
downstream frame 70 provides a transmission rate of 26.112 
Mbps, which is compatible for DVB modem transmission at 
either 64 QAM in a 6 MHz channel or at 16 QAM in a 8 
MHz channel; the six DVB slot downstream frame 72 
provides a transmission rate of 39.168 Mbps, which is 
compatible for modem transmission at either 256 QAM in a 
6 MHz channel or at 64 QAM in an 8 MHz channel; and the 
eight DVB slot downstream frame format 74 provides a 
transmission rate of 52.224 Mbps, which is compatible for 
modem transmission at 256 QAM in an 8 MHz channel, 
respectively. 

In preferred embodiments, a sixty-eight byte upstream 
data frame 58 (not shown in FIG. 4) is employed, which 
provides an upstream data rate of 2.176 Mbps, based on the 
preferred 250 usee upstream transmission interval. This 
upstream data frame length is advantageously evenly divis- 
ible into any of the aforementioned exemplary preferred 
downstream frame format rates — i.e., at a 12:1 ratio with 
respect to the four DVB slot frame 70; at an 18:1 ratio with 
respect to the six DVB slot frame 72; and at a 24:1 ratio with 
respect to the eight DVB slot frame 74, respectively. Various 
preferred upstream frame configurations are described in 
greater detail in conjunction with FIGS. 9-15. 

Referring to FIG. 5, a four DVB slot downstream frame 
70 is depicted with the respective sync, ATM cell and FEC 
bytes omitted for purposes of illustrating a preferred control 
byte configuration. In accordance with yet another general 
aspect of the *088 application, the respective control bytes 
retain their DVB standard position, but their content has 
been altered for purposes of upstream bandwidth allocation 
by the HEMAC 28. In particular, control bytes CTL0-2 of 
the first DVB slot pair (i.e., DVB slots "one" and "two") are 
serially aligned with the respective control bytes CTLO-2 of 
the second DVB slot pair (i.e., DVB slots "three" and 
"four") to form a six byte control subframe 76. The control 
subframe 76 is used to carry MAC overhead from the 
HEMAC 28 to the respective NT MACs 38, including the 
respective upstream transmission permits 50 used by the 
HEMAC 28 to assign upstream bandwidth to respective NTs 
26. 
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With respect to the first DVB slot pair of the control 
subframe 76, control byte CTL0 includes a first (one bit) 
frame flag F0 and seven bits MAC payload data; control byte 
CTL1 includes a second (one bit) frame flag Fl and seven 

5 bits MAC payload data; and control byte CTL2 includes 
eight bits MAC payload data, respectively. The collective 
twenty -two bits of MAC payload data from these first three 
control bytes CTL0-2 form a MAC control data field 78. 
The MAC control data field 78 includes three indicator bit 

10 flags: an acknowledge window flag 75, an ATM expansion 
channel indicator flag 77 and a collision feedback indicator 
flag 79, respectively, followed by a nineteen bit upstream 
transmission permit 50. As illustrated in greater detail below, 
the flag 75 is used to mark the beginning of a new series of 

15 downstream data frames 48 for tracking downstream data 
transmission; flag 77 is used to indicate whether an ATM 
expansion cell 96 (explained in conjunction with FIG. 8) is 
used in the present downstream data frame 48; and flag 79 
is used to indicate whether collision feedback information is 

20 present in data field 80 (explained below). 

The permit field 50 includes a four bit "permit type" field, 
a three bit "call ID" field and a twelve bit "permit ID" field, 
respectively. In particular, the permit type field 81 distin- 
guishes between different "types" of upstream data to be 

^ transmitted by a respective NT 26 in response to receiving 
the permit 50. In a currently preferred embodiment, 
upstream transmission data types include constant bit rate 
("CBR"), variable bit rate ("VBR") and unassigned bit rate 
("UBR") services, respectively, each of which are trans- 

30 ported in a standard ATM cell format. The permit type field 
81 is also used to indicate the type of upstream transmission 
that is offered, i.e., whether it is a reserved slot or whether 
it may be contended for by some or all of the NTs 26. The 
call ID field 83 is used to identify a specific calling channel 

35 or fine for CBR service at a specified NT. The permit ID field 
85 is used to identify a specific NT 26, or group of NTs, if 
applicable, that may respond to the permit. A more detailed 
description of the permit type 81, Call ID 83, and permit ID 
85 fields is provided below in conjunction with FIGS. 9-18. 

40 In the second DVB slot pair of frame 70, control byte 
CTL0 includes a third (one bit) frame flag F2 and seven bits 
MAC payload data; control byte CTL1 includes a fourth 
(one bit) frame flag F3 and seven bits MAC payload data; 
and control byte CTL2 includes eight bits MAC payload 

45 data, respectively. The collective twenty-two bits MAC 
payload data of the second DVB slot pair may be used to 
carry either a twenty -one bit collision feedback information 
field 80 (with one bit spare) or, alternately, a two byte OAM 
data field 82 (with six bits spare). If a collision feedback data 

50 field 80 is being transmitted, the flag 79 is set (i.e., with a 
"1"); otherwise an OAM data field 82 is presumed. 

In particular, a collision feedback data field 80 contains a 
five bit slot identification number 87, followed by six, 
two-bit collision identification flags 89, and a four bit 

55 channel identification number 91, respectively, the use of 
which is described in greater detail below, in conjunction 
with FIG. 9. An OAM data field 82 is used for transporting 
two bytes of OAM data from the headend facility 22 to 
respective NT locations 26. In a presently preferred 

60 embodiment, a protocol for using the OAM data field 82 is 
left open as a design choice by the network implementor. 

Referring to FIG. 6, a six DVB slot downstream frame 72 
is also depicted without the sync, ATM cell and FEC bytes, 
respectively, wherein the collective nine control bytes of 

65 frame 72 form an "expanded" control subframe 84, The first 
six control bytes (i.e., from the first four DVB slots) of the 
expanded control subframe 84 are allocated in the exact 
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manner as in control subfirame 76 of FIG. 5, including a 
nineteen bit upstream transmission permit 50. 

In accordance with yet another general aspect of the '088 
application, only one permit field 50 is used in each down- 
stream data frame per upstream RF carrier channel. Thus, if 
only a single upstream carrier channel is employed in 
network 20, the remaining three control bytes of subframe 
84 (it., control bytes CTLO-2 of DVB slots "five" and 
"six"), which also includes fifth and sixth (one bit) frame 
flags F4 and F5, respectively, are used for other purposes, 
such as for an additional two byte OAM data field 86. It may 
be desirable to expand upstream network capacity by uti- 
lizing an additional RF carrier channel for upstream frame 
transmission — i.e., where a first group of NTs 26 are asso- 
ciated with a first selected upstream RF carrier channel and 
a second group of NTs 26 are associated with a second 
selected upstream RF carrier channel, respectively. In this 
case, the final three control bytes of expanded control 
subframe 84 are used to transmit a nineteen bit "second 
channel" upstream transmission permit 88, which comprises 
a respective four bit permit type field, three bit call ID field, 
and a twelve bit "permit ID" field, (not shown), respectively, 
for a second upstream RF carrier channel. 

Referring to FIG. 7, capacity for yet another upstream 



to 



20 



channel — i.e., associated with the 1st channel permit 
50 — will be illustrated in conjunction with the remaining 
drawings, unless otherwise indicated. 

Referring to FIG. 9, in order to determine if any new NTs 
26 have been activated in the network 20, the HEMAC 28 
periodically transmits a downstream contention "signon" 
permit 180 for each active upstream carrier channel. In 
particular, referring back to FIG. 5, the HEMAC 28 inserts 
a selected four bit binary code in the permit type field 81 of 
permit 50 to indicate that the permit is for a responsive 
signon slot, and a selected twelve bit binary code in the 
permit ID field 85 (i.e., "all NTs"), which indicates that any 
NT 26 may attempt a response. In this manner, a newly 
activated NT 26 will recognize a contention signon permit 
180 and will attempt an upstream response thereto. 

Referring back to FIG. 9, as indicated by dashed lines 
181, more than one NT 26 can respond to a signon conten- 
tion signon permit 180, — i.e., it is a contention mode permit. 
However, preferably only those newly activated NTs 26, i.e., 
those NTs whose signon has not yet been acknowledged by 
the HEMAC 28, will attempt a response. More particularly, 
an NT 26 responding to a signon permit 180 transmits an 
eleven byte upstream signon slot 182, which is followed by 
fifty seven bytes of guard (or "blank") space 184, to com- 



carrier channel is provided by employing an eight DVB slot 25 plete a sixty-eight byte upstream frame 58. In a currently 

downstream frame 74, wherein the collective twelve control preferred embodiment, the upstream signon slot 182 

bytes of frame 74 form a "further expanded" control sub- includes a five byte preamble 186, a four byte unique serial 

frame 90. The first nine control bytes (i.e., from the first six number (e.g., MAC address) 188 of the responding NT 26, 

DVB slots) of the further expanded control subframe 90 are and two bytes FEC information 189, respectively. The 

allocated in the exact manner as in the expanded control 30 preamble 186 is used to insure the headend receiver (not 

subframe 84 of FIG. 6, — i.e., including a first channel permit shown) can accurately receive and read the data contained in 

50 and either an (additional) OAM data field 86 or a second the upstream signon slot 182. Because there is no previously 

channel permit 88, respectively. The remaining three control established synchronization between the headend 22 and the 

bytes (i.e., control bytes CTLO-2 of DVB slots "seven" and respective NT 26, each NT 26 is preferably assigned with a 

"eight"), are used to transmit yet another two byte OAM 35 preset transmission delay to correspond with a selected 

data field 92, or a nineteen bit "third channel" upstream "maximum" transmission delay assigned by the HEMAC 28 

transmission permit 94. The third channel permit 94 includes (explained in further detail below), so that transmission of a 

a respective four bit permit type field, three bit call ID field, signon slot by a respective NT 26 does not interfere with a 

and a twelve bit "permit ID" field, (not shown), for a third previously transmitted upstream frame 58 by another NT. 

upstream RF carrier channel. The final three control bytes of 40 Further, the guard time 184 following the upstream signon 



subframe 90 also include seventh and eighth (one bit) frame 
flags, F6 and F7, respectively. 

Referring to FIG. 8, additional upstream carrier channels 
may also be controlled by expanding into the space starting 
after the first five bytes of the first ATM cell — i.e., ATM cell 
#1 in DVB slot "one"— of the respective downstream frame 
48. In particular, a six byte ATM "expansion channel" 96 is 
allocated in a manner similar to the six byte control sub- 
frame 76 depicted in FIG. 5, except that no framing bits are 



slot is included to help insure the signon slot 182 does not 
interfere with an ensuing upstream data frame 58 transmitted 
by another NT 26. For this reason, no upstream payload data 
is transmitted along with the upstream signon slot 182. 
45 Referring again back to FIG. 5 in conjunction with FIG. 
9, the collision feedback data field 80 is used by the HEMAC 
28 to provide feedback information to the respective NTs 26 
regarding the success or failure of an attempted response to 
a contention signon permit 180. More particularly, in order 



needed. Up to eight, six byte control sub frames may be 50 to track the successive downstream frames 48, a five bit 

added to the first ATM cell following the excluded first five binary slot number is assigned to each frame, wherein the 

bytes. The use of an ATM expansion channel 96 is indicated slot numbering starts over after each successive thirty-two 

by setting flag 77 in the MAC control field 78 of the first frames (i.e., from slot number "00000" to slot number 

DVB slot of the respective frame 48. In a presently preferred "11111"). The beginning of a new series of slot numbers is 

embodiment, a six byte expansion channel 96 includes a 55 indicated by setting flag 75, so that each NT can easily track 



further one bit collision feedback flag 93, a further channel 
upstream permit 94, and an associated collision feedback 
data field 95, respectively. The further upstream permit 94 is 
identical in format to permit 50, and may be used as an 
alternate second or third channel permit — i.e., where only a 
four or six DVB slot frame configuration is employed. 
Likewise, the collision feedback data field 95 is identical in 
format to field 80, wherein use of field 95 is indicated by 
setting flag 93. 

Although the use of multiple upstream channels is thus 
provided for in the present preferred embodiment, for pur- 
poses of ease in illustration, only a single upstream 



the respective downstream frames by monitoring the flag 
and employing a simple frame counter (not shown). As will 
be apparent to those skilled in the art, this also allows further 
downstream communication regarding the results of an 
60 upstream transmission to be easily identified, so long as it is 
transmitted by the HEMAC 28 within thirty-two frame 
periods since the original downstream permit 180 was 
transmitted. 

If a responsive signon slot 182 is successfully received by 
65 the HEMAC 28 (i.e., without an inherent transmission 
problem or collision occurring between respective NTs 
attempting a response), the collision feedback data field 80 
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will identify the slot number (Le., from 00000 to 11111) of a delay of T^, and NT#y imposes a delay of T dely , 

the respective downstream frame 48 containing the signon respectively, before each transmits a respective upstream 

permit in field 87. The first two-bit collision indicator "CH" response, e.g., to a contention permit contained in the 

in field 89 is then set to "01", with the remaining five two-bit respective downstream frame. Based on the ranging permit 

indicators left at zero. In this manner, the successfully 5 process, the HEMAC sets the respective delays, and 

responding NT's MAC 38 (which has stored the correspond- T <fe/y> such that the total round trip transmission time is the 

ing slot number of the frame 48 carrying the contention same for both N* 1 ** nd NT*y> i- e -» 2 T*+T^-2T y +T^;y In 

signon permit 180) will know that its signon slot was ^ a11 upstream frames 58 ^ will amve serially at the 

received by the HEMAC 28. headend 22, regardless of the differences m round trip 

. , „ n transmission times between respective NTs 26. Where the 

In a case where two or mote NTs 26 transmit an upstream » tiaD&missioa of a respective m 26 is found to 

signon slot 182 in response to the same downstream signon exceed , he fous maximum dd ^ ^ HEMAC wm 

!™ - « ',? e eo ^» ? ?" ° l0D ' ° accordingly update each of the NTs 26 with a compensating 

"CIl" infield 89 to "ll", mdicating .hat no signon aUempt dd y * to Qr tH ^ ^ ^ 

by any NT 26 was effective. Aprotocol for re -attempting an network terminal del mtervaL 

upstream response by the respective unsuccessful NTs while 15 _ ., . ... . . . . . . . 

„ , -aI^u ii ■ • • c li i j Because the initial transmission delay for receiving a 

attempting to avoid further collisions is preferably employed ... . ' ,„., °. 

by the respective NTs 26. Such protocols include many respo ° s f 0 t ° elthe , r b a contentl ° n signon permit 180 or rangmg 

, rf. . , ... * , • u -m i i permit 190 is not known, a number of "blanking slots (not 

known efficient contention resolution Random Access algo- r , x . ' , „ „ . iL . b . . v „ 

rithms (RAA), such as the Ternary Tree Binary Feedback s *° wn ) "* *f? My l°"? wm 8 transmission of 

/t-tt>i?\ i -iu u ** vrr • j on either one of these permits. A blanking slot is simply a 

(11 KF) algorithm, wherein respective NTs are assigned 20 4 f, . 4 „ . , i ■ , 4 . 5 \. 

\.«. . . . e u 1 -*u • * *i j * non-transrmttmg, or quiet period, equal in length to the 

differing priority numbers. Such an algorithm is tailored to . £ . ° , i . f. „ 1 A n x r 4l _r 

& \ , c , .. & , . j normal frame interval timmg (i.e., 250 usee). In this manner, 

systems with a large number of stations and outperforms KT ~ , v . ion. ■ 

; rnuA , ... & . „ . c * u i * tne responding NTs 26 to a signon permit 180 or ranging 

ALOHA algorithms without suffering from its stability -^nn rr j j ,iv v\- ■ * ir f L ■ 

L1 r . r , * *■ 1 ** permit 190 are afforded an additional time interval for their 

problems. An overview of known contention resolution r , . ... u.uujjm-.u. 

i , j . Trrr n< upstream transmission to reach the head-end 22, without 

algorithms is provided in a paper presented to the IEEE 25 . \ c . . iL . A 4 , 

ii • * om h/ti; i • j « a r n mterfenng with an ensuing upstream response to a subse- 

Project 802.14 Working Group entitled, A review of Ran- ueQt closer NT 

dom Access Algorithms", by Chatschik Bisdikian of IBM, - ? , , .* ... 

dated January 1996, which is fully incorporated herein by r Further ' where the respective round tap transmission time 
reference a P artlcll l ar NT 26 exceeds the total frame transmission 

slot time (i.e., 250 usee in the illustrated preferred 



In situations where multiple upstream frequency channels 6mbodiments)j no delay can be accommo dated, since 

are used by <he network 20, a four bit channel number^ is ^is will cause interference between sequential adjacent 

provided in field 91 by the HEMAC 28 to identify which ream &am6S 5g Instead> Qnc Qr mQre blankin ^ 

upstream channel the mformation in field 80 apphes to. A mus , be permanenay inserted by me H EMAC 28 following 

desenpfon of the use of the remammg two-bit coition cach downstr6am frame 48 toansrnissioa k which 0 ne or 

mdicators in field 89 is described below in conjunction with more such <<long distance „ ^ m ^ respoad Jn 

order to maintain efficient utilization of network bandwidth, 

Referring to FIG. 10, where an NT 26 does successfully however, the respective NTs 26 of a preferred network 20 

submit a signon slot 182 to the HEMAC 28, it assumes the should be sufficiently close to the headend 22 so that the 

particular twelve bit NT ID transmitted in the particular 4Q number of blanking slots required to insure receipt of signon 

downstream signon permit 180. The HEMAC then transmits an d ranging responses does not cause overall network band- 

a "ranging permit" 190 to the respective NT 26 in order to width utilization to suffer. 

determine (and subsequently adjust) the round trip transmis- Referring to FIG. 12, in accordance with yet another 

sion interval between the two units. In particular, the ranging general of me , 088 app H C ation, the HEMAC 28 will 

permit 190 is addressed only to the specific NT 26, by way 45 periodica i ly a reservation mode permit 200, which 

of the 12 bit permit ID field 85. Thus, there is no "conten- allows for me U p Streai n transmission of an ATM payload cell 

tion" situation between respective NTs 26, as only the 62 by a specific NT 26. The HEMAC 28 identifies the permit 

specifically identified NT may respond. type ^ bdng « rese rvation mode" by a selected code in the 

To respond to a ranging permit 190, the polled NT 26 permit type field 81 of the downstream permit 200, with the 

transmits an eleven byte ranging slot 192, followed by fifty 50 particular NT 26 being identified in the 12 bit permit ID field 

seven bytes of guard space 194. The ranging slot 192 85. 

includes a five byte preamble 196, the four byte unique serial The specified NT 26 responds to the reservation mode 

number 198 for the respective NT 26, and two bytes FEC perm j t 200 by transmitting an upstream data frame 58 

information 199, respectively. The HEMAC 28 tracks the containing a non-contention request slot 202, followed a 

time between when it transmits the downstream ranging 5S fifty-three byte ATM payload cell 62 and six bytes of FEC 

permit 190 and when it receives the responsive ranging slot information 209, respectively. The non-contention request 

192 from the respective NT 26 and compares the round trip s i 0 t 202 includes a five byte preamble 206 and a four byte 

transmission time against the currendy existing maximum non-contention request 207. The non-contention request 207 

delay time and calculates the difference in order to set the includes contains a one byte OAM field 201, four bits spare, 

proper delay for the respective NT 26. The respective delay 60 a f our bi( «ge ne ric queue type" field 203, a six bit "generic 

information is then transmitted to the particular NT 26 as queue size" field 205, a six bit "VBR queue size" field 208, 

part of the OAM provisioning data contained in an ensuing m ^ a f our bit "CBR request" field 204, respectively. As 

downstream data frame 48. explained in greater detail below in conjunction with FIGS. 

By way of illustration, referring to FIG. 11, a downstream 16-17, the VBR queue size field 208 is used by the NTMAC 

frame 48 is transmitted from the headend 22 and is received 65 38 to inform the HEMAC 28 of the number of ATM payload 

at NT#x after a transmission interval of T x , and is received cells 62 it has waiting in its VBR queue (shown in FIG. 16). 

at NT#y after a transmission interval of T y . NT#x imposes The generic queue size field 205 is used by the respective 
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NTMAC 38 to inform the HEMAC 28 of the number of 
ATM payload cells 62 it has waiting in a given queue of a 
service type indicated by a selected code in the generic 
queue type field 203. The CBR request field 204 is used by 
the respective NT MAC 38 to request CER bandwidth for up 
to four CER connections — , i.e., wherein each respective bit 
is used to indicate whether an associated telephone line or 
connection at the respective NT 26 is "off-hook". 

Referring to FIG. 13, the HEMAC 28 may also periodi- 
cally transmit a contention mode permit 210, which allows 
for the upstream transmission of an ATM payload cell 62 by 
a responsive NT 26, but is "contention based/' so that any 
NT 26 may respond, as indicated by dashed lines 193. The 
HEMAC 28 identifies the permit type as being "contention 
mode" by a selected code in the permit type field 81 of the 
downstream permit 200. In a presently preferred 
embodiment, the HEMAC may designate either one or more 
particular groups of NTs 26, or all NTs 26, as being eligible 
to respond to the contention mode permit 210, by inserting 
a particular 12 bit group code in the permit ID field 85. 

An NT 26 responds to a contention based ATM permit 210 
by transmitting an upstream data frame 58 containing a 
"contention request" slot 212 followed a fifty-three byte 
ATM payload cell 62 and six bytes of FEC information 219, 
respectively. The contention request slot 212 includes a five 
byte preamble 216 and a four byte contention request 217. 
The contention request 217 includes a twelve bit source ID 
field 211, a four bit generic queue type field 213, a six bit 
generic queue size field 215, a six bit VBR queue size field 
218, and a four bit CDR request field 214, respectively. The 
respective generic queue type field 213, generic queue size 
field 215, VBR queue size field 218, and CBR request field 
214 are used in an identical manner as fields 203, 205, 208 
and 204, respectively, of a non-contention request — i.e., a 
contention request 217 is the same as a non-contention 
request 207, except that the twelve OAM/spare bits of the 
later are used as a source I.D. field 211 in the former for a 
inserting a responding NT's MAC address. 

In a presently preferred embodiment, the collision feed- 
back data field 80 is used by the HEMAC 28 to provide 
feedback information to the respective NTs 26 regarding the 
success or failure of an attempted response to a contention 
mode permit 210 in the exact same manner as with the 
contention signon response slots 182 described above in 
conjunction with FIG. 9. In the case where two or more NTs 
26 transmit an upstream contention request slot 212 in 
response to the same downstream contention mode permit 
210, the HEMAC 28 will set the collision indicator "CI1" in 
field 89 to "11", indicating that no ATM payload cell 62 was 
received and that retransmission is required, e.g., in accor- 
dance with the afore-described RAA algorithms. Again, in 
situations where multiple upstream frequency channels are 
employed by the network 20, a four bit "channel number" is 
provided in field 91 by the HEMAC 28 to identify which 
upstream channel the information in field 80 applies to. 

Referring to FIG. 14, the HEMAC 28 may also periodi- 
cally transmit a "block request" polling permit 220, which 
polls up to six different NTs 26 on an individual (i.e., 
reservation mode) basis, to allow for each designated NT 26 
to send an eleven byte upstream "mini request slot" 222 in 
a respective reserved request slots 222. The HEMAC 28 
identifies the permit type as being a "block request" by a 
selected code in the permit type field 81 of the downstream 
permit 220. In a presently preferred embodiment, the 
HEMAC 28 assigns (e.g., by way of provisioning informa- 
tion sent in past OAM data fields) each NT 26 to belong to 
one or more "polling groups" of up to six NTs. Each NT 26 
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in a particular polling group is also assigned a "mini slot" 
position number, i.e., from one to six. 

To respond to the block request permit 220, the selected 
NTs of the polling group identified by a selected code in the 

S 12 bit permit ID field 85 each transmit an eleven byte mini 
request slot 222 in its selected slot position. By way of 
example, in the preferred embodiment depicted in FIG. 14, 
NTs 26a, 26£> and 26c each belong to a selected polling 
group, wherein NT 26a is assigned to mini slot 1, NT 26b 

]0 is assigned to mini slot 2 and NT 26c is assigned to mini slot 
6, respectively, for their respective response transmission, 
wherein the total transmission interval of the mini slots is 
equal to the total 250 usee upstream frame interval. In a 
presently preferred embodiment, each NT MAC 38 is pro- 

15 vided with a separate delay counter for determining its 
transmission slot timing, in addition to the afore-described 
transmission delay of the respective NT 26 due to its 
distance from the headend 22. 
Each mini request slot 222 includes a five byte preamble 

20 226 followed by a four byte request 227 that is identical to 
a non-contention request slot 207 (described above in con- 
junction with FIG. 12) and two bytes FEC 229. As will be 
apparent to those skilled in the art, the twelve bit ID of the 
respective NTs is not required, since the HEMAC 28 already 

25 knows which NTs 26 are responding in each mini slot. 

Referring to FIG. 15, to accommodate a greater number of 
upstream communication requests without having to poll 
each NT 26, the HEMAC 28 may also periodically transmit 
a "group contention permit" 230, which allows any NT of a 

30 specified group to send an upstream request contained in a 
respective eleven byte, "mini contention request" slot 232. 
In a presently preferred embodiment, each NT 26 of the 
specified group is allowed to contend for any one of up to six 
respective mini slot positions of a responsive upstream 

35 frame 58, as indicated by the dashed line 195, although it 
may only contend for a single mini slot position, per group 
contention permit 230. The eleven byte contention request 
slot 232 is identical to the afore-described eleven byte 
contention mode request slot 217, including a twelve bit 

40 source ID field. As with the afore -described reservation 
mode polling requests 222, however, no upstream data is 
transmitted. 

In a presendy preferred embodiment, the collision feed- 
back data field 80 is used by the HEMAC 28 to provide 

45 feedback information to the respective NTs 26 regarding the 
success or failure of an attempted response to a group 
contention permit 230 in substantially the same manner as 
with the contention request and signon response slots 212 
and 182, respectively, as described above in conjunction 

50 with FIGS. 9 and 13. However, because there are actually six 
mini slots being contended for by the responding NTs 26, 
each of the six, two-bit collision indicator fields 89 (i.e., 
CI1-CI6, respectively (seen in FIG. 5) are used. In 
particular, if there is a collision detected in any of the six 

55 mini slots, the HEMAC 28 will set the collision feedback 
field for the respective channel and populate each of the 
respective collision indicator fields 89, as follows: if the 
respective mini slot was empty (i.e., "no carrier") the field 
is set to "00"; if a mini contention request slot 232 is 

60 successfully received in a respective mini slot, the field is set 
to "01"; and if there is a collision in a respective mini slot, 
the respective field is set to "11", indicating that no request 
232 was received in that particular mini slot and that 
retransmission is required, e.g., in accordance with the 

65 afore-described RAA algorithms. Again, in situations where 
multiple upstream frequency channels are employed by the 
network 20, a four bit "channel number" is provided in field 
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91 by the HEMAC 28 to identify which upstream channel upstream bandwidth of the particular upstream channel 

the information in the collision feedback field 80 applies to. assigned to the respective NT 26. 

Block request permits 220 or group contention permits Respective upstream request slots are populated as fol- 

230 are preferably issued by the HEMAC 28 on a regularly lows: 

scheduled basis to better ensure upstream transmission s „ . . 

access to all NTs When responding to all reservation or contention mode 

Referring to FIG. 16, the HEMAC 28 receives one or pcrm . its s ^ on or n ^ l J^ a ^;^ a6 S ! ZC 

more downstream digital data streams 102 from various data counten ; " 0 ™ oml ° r respecti ve VBR and UBR service 

service interfaces such as, e.g., POTS telephony interface W™"* U6 . and l18 ' . numb " of P eadm 8 ^ 

30, ATM interface 32 and LAN interface 34, respectively, 10 cells awaiting upstream transport m each respective service 

(shown in FIG. 1) for transmission to the respective NTs 26. «W° <l ueue - The counters provide an updated cell count to a 

The respective data streams 102 are fed into a frame request slot assembler 131 for each respecUve service type 

assembler 104, which, in accordance with the afore- queue, the request slot assembler 131 uses this information 

described framing protocol described in conjunction with 10 P°P ulate respective "queue size" fields in the next out- 

FIGS. 3-8, assembles the received data into respective 1S gomg request slot. In me .Uustra^ preferred embc^ent 

downstreamdataframes48fortransmissionoverthecoaxial °™. 16, the generic queue fields (e.g., fields 203/205 

distribution network 24. The assembler 104 also receives 213/2 , 1S ° f mGS - 12 ^) ln Jhe respective upstream 

periodic contention feedback data, referred to generally in ^ <"•> slots 202 ' 212 ' 222 and 232 of HGS - 

FIG. 16 as the contention feedback data field "80" described J?! 15 *" 6 f 6 ? * 1130511111 ^' q "? e SlZC .° f ** UB * 

above in the text accompanying FIG. 5, and successive „ U8 ' ^L^, 8 en f n c type field containing a code indi- 

upstream bandwidth permiU, referred to generally in FIG. c L atlD 8 UBR s « VIoe - . Io a^ate preferred embodiments, 

16 as the permits 50 described above in the text accompa- ,he ™P«* ve "tpxac queue" fields of the upstream 

nying FIG. 2, for inclusion in the MAC control information re f esls ™1 be MAC 38 '? send 

(e.g., subframc 76 in FIG. 5) of the respective downstream ^formation to the HEMAC 28 regarding any number of 

data frames 48 different service type queues, either on a dedicated or 

As each downstream data frame 48 is received by a * ^^^^ e ^^ a '^ teuBStiCmbmd - 

respective NT26, the frame 48 is input into a dissembler 106 ^ ^ " 

located in the NT MAC 38. If it is an intended recipient of Because of its relatively high service level priority, VBR 

the data contained therein, the disassembler 106 strips off the semces are P refe ™bly given a dedicated queue field in the 

framing overhead and parses the downstream data 108 into 30 u P stream requests. 

respective data streams for further processing (not shown) A CBR service monitor (not shown) monitors telephony 

by the NT MAC 38. The frame disassembler 106 also channels 122a-d for activity— e.g., such as an initial off- 

recovers the respective permit 50 in the MAC control hook detection — and reports the status of each telephony 

overhead of the downstream frame 48 — i.e., pertaining to channel to the request slot assembler 131. This information 

the upstream frequency channel assigned to that NT 26. The 35 is used to populate the "CBR request" field (e.g., fields 204 

NT MAC 38 then evaluates the respective permit 50 by and 214 of FIGS. 12 and 13) of the upstream requests. For 

reading the respective permit type and ID fields and, if a example, in a presently preferred embodiment, each of the 

response is either required or desired, the recovered permit ^out bits of the CBR request fields is assigned to a corre- 

50 is input into a ranging delay circuit 110. In a manner sponding telephony channel I12a-<1 In each upstream 

described above in conjunction with FIGS. 10-11, the 40 request slot , the request slot assembler 131 sets the respec- 

ranging delay circuit 110 delays the permit within the NT tive bit of the CBR request field to "1" if the corresponding 

MAC 38 for a preset period of time, such that the responsive telephony channel is active and otherwise sets each bit to 

upstream transmission of a response slot is serially coordi- I Q alternate preferred embodiments, the generic queue 

nated with the upstream frame interval timing. Following fields mav De used to send status information regarding 

the delay period, the permit 50 is input into an upstream 45 further CBR telephony channels. As explained in greater 

transmission controller 112. Upon receipt of the permit, the detail below, CBR trarfic requires very low CDV. As such, 

controller 112 immediately triggers the upstream transmis- CBR queues lX4a~d preferably store no more information 

sion of a responsive upstream data frame 58 by a packet 10411 the data of a cell currently being assembled, 

assembler 120, depending upon the type of upstream For all upstream requests, including signon and ranging 

response called for by the respective permit (50). 50 permits (i.e., permits 180 and 190 of FIGS. 9 and 10), the 

More particularly, within the NT MAC 38 are a plurality respective NT ID information for the request slots is pref- 

of ATM cell queues, including CBR queues 114a-d, VBR erably supplied directly by the packet assembler 120. A 

queue 116 and UBR queue 118, respectively, wherein "mini slot" timing counter 123 is employed to add a further 

respective upstream data streams are serially assembled into calculated delay to upstream frame transmission in cases 

successive ATM cells 62 in the respective queues. In the 55 where a mini request slot is being transmitted in response to 

illustrated preferred embodiment of FIG. 16, CBR queues a group contention or polling permit (i.e., permits 220 and 

114a-d assemble respective ATM cells 62 containing CBR 230 of FIGS. 14 and 15). As with the ranging delay circuitry 

service data representing synchronous telephony PCM data 110, the delay value of circuit 123 is supplied by the 

from corresponding telephony channels 122a^d. VBR queue HEMAC 28 by way of OAM provisioning data. 

116 assembles and, depending on network traffic conditions, 60 The respective upstream data frames 58 are received by 

stores ATM cells (62) containing digital VBR service data. the HEMAC 28 and input into a frame disassembler 132, 

Likewise, UBR queue 118 assembles and, as necessary, which strips the respective request slot(s) from any data 134 

stores ATM cells (62) containing digital UBR service data. and/or OAM information (not shown) contained in an 

As will be apparent to those skilled in the art, any number appended ATM cell. In accordance with a more particular 

of service type ATM cell queues may be used by the NT 65 aspect of the '088 application, a copy of each permit 50 input 

MAC 38 in accordance with the transmission protocol into the downstream frame assembler 104 is delayed by 

methodology provided herein, limited only by the available respective HEMAC delay circuitry 144, and input into the 
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frame disassembler 132, respectively. The HEMAC delay wherein the VBR queue size for of each NT 26 is placed into 

circuitry 144 delays the each successive permit 50 to match a respective "leaky bucket register" ("LBR") 157. Likewise, 

to overall round-trip transmission timing of network UBR queue information 167 is parsed into a UBR band- 

20 — i.e., such that each respective permit 50 will arrive at width manager 155, wherein the UBR queue size for each 

the frame disassembler 132 at the same time as the respon- 5 NT 26 is also placed into a respective LBR 161. CBR 

sive upstream request slot. request data 169 is parsed directly into a CBR permit 

Depending on the respective permit type and responsive scheduler 156. 

request slot, the frame disassembler 132 will extract the Within the respective bandwidth managers 153 and 155, 

pertinent data contained in each received request slot and permits of the same service priority for different NTs 26 are 

pass it into a first queue selector 136, for further processing 10 issued on a "round robin" basis by selectors 159 and 163, 

by the HEMAC 28. In cases where a reservation mode respectively. In particular, round robin selector 159 in the 

permit was issued — i.e., either a ranging permit 90, regular VBR bandwidth mgr 153 successively issues a "VBR" type 

reservation permit 100, or a group polling permit 120, permit into a VBR permit queue 152 for each successive NT 

respectively — the disassembler 132 must first append the LBR 157 having at least one VBR cell in queue. Likewise, 

respective network terminal ID information from the permit 1 5 round robin selector 163 in the UBR bandwidth mgr 155 

50 to the received request slot. In this manner, all requests successively issues a "UBR" type permit into a UBR permit 

received by the queue selector 136 (excepting signon and queue 154 for each successive NT LBR 161 having at least 

ranging slots 182 and 192) will contain the same data fields, one UBR cell in queue. In this manner, each NT having at 

regardless of whether the slot was originally in response to least one cell in queue of a respective VBR or UBR service 

a contention or reservation mode permit. 20 type is given an equal allocation of the available upstream 

For received signon slots 182, the disassembler 132 bandwidth for that respective service level, even though 

transmits the four byte NT ID field directly to an internal other NTs may have a much larger queue size. 

HEMAC processor 133. If a four byte ID was successfully Instead, the LBR registers 157 and 161 act as a "gate" for 

received, the processor 133 stores the information in an the incoming request information. Whenever a request 

associated memory 135 and issues an ensuing ranging 25 arrives from a respective NT 26, the associated LBR 157 and 

permit. The processor 133 also issues a feedback message 161 are incremented by the number of new cells in each 

129 regarding the success (or lack there of) of the response respective service queue. The respective LBRs 157 and 161 

for placement in the pertinent collision feedback data field of are also decremented at a selected mean rate allocated to that 

an ensuing downstream data frame 48, via a contention particular NT. The individual LBRs 157 and 161 are each 

processor 140 (described below). 30 defined by a top threshold, or "burst size." So long as the 

Where a ranging response slot 192 is received, the dis- respective LBR queue register is below this threshold, all 

assembler stops a ranging delay measurement clock 146, incoming requests are allowed to into the respective outgo- 

which was activated by the respective permit 50. The overall ing permit queue 152 or 154. If the threshold is exceeded, 

transmission time is then relayed from the clock 146 to the however, no further permits are issued until the respective 

processor 133 for further handling as described above. 35 LBR "leaks" below the threshold. 

For all other received request slots, the HEMAC performs Referring again to FIG. 16, a permit priority selector 158 

the following processing steps: feeds the respective permits from the VBR and UBR queues 

With respect to contention requests, (i.e., contention 152 and 154, and from the CBR permit scheduler 156, 

requests 217 and 227 in FIGS. 13 and 15, respectively), the 40 respectively, to the downstream frame assembler 104. Occa- 

queue selector 136 attaches the downstream frame transmis- sional signon and ranging permits (i.e., 180 and 190) issued 

sion slot number of the respective permit (i.e., as described directly from processor 133 into a separate queue 137 are 

above in conjunction FIGS. 5 and 9) to the responsive also input into the downstream assembler 104 frames by 

request data and then transmits the respective requests into priority selector 158. 

a contention request processor 140. The contention request 45 In accordance with another general aspect of the '088 

processor 140 reads the respective data fields in each request application, CBR permits from the CBR scheduler 156 are 

to determine if (1) a response was successfully received, (2) generally given top priority by the priority selector 158, due 

a collision occurred, or (3) no response was received at all to the very low CDV that must be maintained for these 

(i.e., no carrier), and generates feedback data 138 for a service. VBR and UBR permits from queues 152 and 154 

corresponding collision information field (80). If a conten- 50 each take a respective lower priority, with signon and 

tion request was successfully received, the contention pro- ranging permits from queue 137 typically given the lowest 

cessor 140 inputs the request into a permit selector and priority. 

spacing processor 150. In all cases, the generated feedback 7^ scheduling of CBR permits by the CBR scheduler 

data is forwarded to a collision feedback data queue 142 for 155 ^ pre ferably carried out so that telephony data is 

placement by the downstream frame assembler 104 into the 5S rece ived at the headend 22 at intervals averaging 5.875 

respective MAC overhead field corresponding to the msec, in accordance with synchronous telephony standards, 

upstream frequency channel, e.g., data field 80, of an ensu- m particular, CE telephony "AAL1" standards require the 

ing downstream data frame 48. "packing" of forty-seven bytes of PCM data from a tele- 

Non-contention requests (i.e., requests 207 and 227 in phone channel (e.g., from a single DS0 channel such as 

FIGS. 12 and 14, respectively) are fed directly from the 60 telephony channels 122a-d received at the NT MAC 28 

queue selector 136 into the permit selector and spacing illustrated in FIG. 16) into each CBR ATM cell. As described 

processor 150. in the '088 application, because the data arrives at the NT 26 

Referring to FIG. 17, all requests input into the permit on a one-byte-per 125 usee basis, a 5.875 msec delay with 

selector and spacing processor 150 are first processed by a respect to the first arriving byte is already required to fully 

selector circuit 151, which separates the requests based on 65 pack each cell. When employing the preferred frame interval 

service type and NT ID. In particular, VBR queue ioforma- timing of 250 usee to transmit the frames upstream to the 

tion 167 is parsed into a VBR bandwidth manager 153, HEMAC 28, 5.875 msec will not fall on an even time 
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interval — , i.e., on either 5.75 msec based on every twenty- CBR permit associated with line 170. Upon receipt of the 
three frame intervals, or 6.00 msec based on every twenty- first scheduled CBR permit 173, the NT MAC 38 signals the 
four frame intervals, respectively. cell permits sequencer 176, which triggers an internal timer 
Thus, in order to match the AAL1 frame timing standards, ( not shown ) * res P onse - In Particular, the timer is set for an 
the CBR permit scheduler 156 evenly allocates the CDR s interval equal to the anticipated arrival time of a •permit- 
telephony permits based on a repetitive rotation of forty- ^"P 6 * 175 .' wh £ h wU a ™. e ^V 75 mxc . ^ me _ te 
. « c c l *-*it. permit 173, minus the sum of the time required to collect 
seven downstream frames for each respective telephony ^ Q ^ b for ^ ^ CBR ^ ^ ( . at a 

fT?'J?°J* P^^'l t0 WG. 18, to match the g ^ z k J & of 125 ^ ^ {qt ^ tQtal of 

AAL1 47 byte fill rate of 5.875 msec, the CBR permit 5 875 mscc) md a predeterminc d internal NT transmission 

scheduler 158 employs a scheduling table 160 for issuing 10 ^ processing overhead time ofj in a pre sently preferred 

CBR permits to respective active telephony channels in the embodiment, approximately 0.20 usee, 

respective NTs 26. The scheduling table 160 employs a When lhe timer expireS) iXt> after 11.75-(5.875+0.20)= 

looped counter of forty-seven permit timing interval slots 5>65 mseCj me cell permits sequencer 176 immediately 

162, wherein each slot is associated with a respective 250 activates an AAL1 segmentation and reassembly ("SAR") 

usee downstream frame interval. ^ processor 178, which immediately begins assembly of a first 

For each available timing interval slot 162, a network CBR ATM cell by packing consequtive data sample bytes 

terminal ID 164 and Call ID channel 166 may be assigned received from the line interface module 172. In particular, 

by the CBR permit scheduler 156, based on availability at the line interface module 172 digitally samples an analog 

the time the first "active" flag is set to a "1" in the Call ID ( voice ) si 8 nal from the subscriber line 170 every 125 usee, 

field of an incoming request slot from a respective NT 26. 20 with the samples packed into successive ATM cells by the 

The slot assignment is relayed to the respective NT 26 in an AALl SAR processor 178. 

ensuing downstream data frame 48, i.e., by OAM provi- Prior to receipt of the activation signal from the cell 

sioning data. In a manner described below in conjunction permits sequencer 176, the SAR processor 178 drops the 

with FIGS. 19 and 20, the respective NT 26 thereafter received samples from the line interface module 172. Once 

assembles its respective ATM cells on a "just-in-time" basis, 25 the initial ATM cell is fully constructed, it is transmitted 

so that each respective CBR ATM cell is fully packed and from the SAR processor 178 to a respective CBR queue 

ready for upstream transmission just as the respective permit (e.g., queues Mla-d in FIG. 16) in the NT MAC 38. 

arrives from the HEMAC 28. As will also be appreciated from the present disclosure, 

By way of example, operation of the scheduling table 160 the timer in the cell permits sequencer 176 will cause the 

when two active NT Call ID channels are active is shown in first CBR ATM cell of the newly activated call activation 

FIG. 18. At interval 0002, a CBR permit is allocated for NT sequence to be packed and in position for upstream trans- 

#0520, Call ID #1, and at interval 0025, i.e., after 5.75 msec, mission (i.e., in queue 122), just as the third permit 175 in 

the next successive permit is issued for NT #0520, Call ID the scheduled sequence arrives at the NT 26. As such, the 

#1. Because the timing interval 162 is looped, the next ensuing CBR ATM cells will thereby be synchronized with 

permit for NT #0520, Call ID #1 will occur again at slot the MAC layer permits, and delay time at the NT 26 thus 

0002 of the ensuing loop, i.e., after 6.0 msec. By repeating minimized. 

this loop, the CBR telephony permits for NT #0520, Call ID While embodiments and applications of this invention 

#1 are thus issued at an average interval of 5.875 msec, with have been shown and described, as would be apparent to 

a maximum CDV of ±125 usee, which is well within 4Q those skilled in the art, many more modifications and 

acceptable CDV standards for CBR telephony service, applications are possible without departing from the inven- 

Likewise, at intervals 0023 and 0047, CBR permits are tive concepts herein. 

allocated for NT #0003, Call ID #2. Again, because the For example, while in the above -disclosed preferred 

timing interval 162 is looped, the permits for NT #0003, Call embodiments the permit delay circuitry 110 already takes 

ID #2 are allocated every 5.75 usee and 6.0 usee, 4J into account the delay due to the transmission distance of the 

respectively, for an average interval of 5.875 msec and a respective NT 26, in alternate preferred embodiments, this 

maximum CDV of ±125 usee. delay value may instead be built directly into the cell permits 

In accordance with a general aspect of the invention, the sequencer 176 (i.e., for all permits and not just CBR 

arrival of the scheduled CBR permits is synchronized with permits). 

the assembly and packing of each new CBR ATM cell. 50 The scope of the disclosed inventions, therefore, are not 

In particular, referring to FIG. 19 in conjunction with the to be restricted except in the spirit of the appended claims, 

previous figures, a subscriber line 170 is connected to a a What is claimed: 

line interface module 172 within a respective NT 26, 1. In a communication network comprising a headend and 

whereby the subscriber line 170 is constantly 26 monitored a plurality of network terminals in communication with the 

by an NT application (software) layer 174. Upon detecting 5S headend over a shared communication medium, a method 

an off-hook condition on the subscriber line 170, the NT for synchronizing the delivery of data cells from a network 

application layer 174 signals the NT MAC 38, which sends terminal to the headend with the delivery of upstream 

a request containing the pertinent subscriber line ID (i.e., of transmission permits from the headend to the network 

subscriber line 170) to the CBR permit scheduler 156 in the terminal, comprising the steps of: 

HEMAC 28. Assuming there is sufficient capacity, the CBR 60 initiating the transmission of a series of successive 

permit scheduler 156 assigns the subscriber line 170 to an upstream transmission permits from the headend to the 

available timing interval slot 162, and notifies the respective network terminal, wherein the permits are delivered 

NT 26 (e.g., in an ensuing OAM transmission) that the CBR according to a predetermined schedule; 

permits for line 170 have been scheduled. initiating a timer for a preset duration, upon receipt of a 

Upon detection of the off-hook condition, the NT appli- 65 first permit in the series; and 

cation layer 174 also notifies a cell permit sequencer 176, activating a cell assembly process at the network terminal 

which enters into a "ready" state in anticipation of a first upon the expiration of the timer, wherein the timer 
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duration is set such that a first data cell is assembled 
and ready for upstream transmission upon receipt of an 
ensuing permit in the series. 

2. The method of claim 1, wherein the ensuing permit is 
the third permit in the series. 

3. The method of claim 1, wherein the step of initiating 
the transmission of a series of successive upstream trans- 
mission bandwidth permits from the headend to the network 
terminal comprises the steps of: 

monitoring a subscriber access line associated with the 
network terminal for an off-hook condition; and 

transmitting an upstream bandwidth request to the head- 
end if an off-hook condition is detected. 

4. The method of claim 3, wherein the upstream band- 
width request is for continuous bit rate service for the 
respective subscriber line. 

5. In a communication network comprising a headend and 
a plurality of network terminals, a method for synchronizing 
the delivery of ATM cells from a network terminal to the 
headend with the delivery of respective upstream transmis- 
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sion permits from the headend to the network terminal, 
comprising the steps of: 

monitoring a subscriber access line associated with the 

network terminal for an off-hook condition; 
initiating the transmission of a series of successive 
upstream transmission permits from the headend to the 
network terminal if an off-hook condition is detected, 
wherein the permits are delivered according to a pre- 
determined schedule; 
1 initiating a timer for a preset duration, upon receipt of a 
first permit in the series; and 
activating a cell assembly process at the network terminal 
upon the expiration of the timer, wherein the timer 
duration is set such that a first ATM cell is assembled 
' and ready for upstream transmission upon receipt of an 
ensuing permit in the series. 
6. The method of claim 5, wherein the ensuing permit is 
the third permit in the series. 

***** 
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